src/github/credentials.ts:171

• New auth behavior (env-token initialization + precedence over VS Code auth) is not covered by tests. Since this impacts core authentication and session/scopes upgrade flows, add unit tests to cover at least: env token present/absent, env token ignored when forcing a new session, and required-scope upgrade interactions.

		const envResult = await this.tryInitializeFromEnvironmentToken(authProviderId);
		if (envResult) {
			return envResult;
		}

src/github/credentials.ts:171

• initialize() now attempts env-token auth unconditionally, which means explicit interactive flows (e.g. forceNewSession, createIfNone: true) can no longer force a VS Code authentication session. This can prevent users from switching accounts or re-consenting scopes unless they manually unset the env var. Consider only using the env token when getAuthSessionOptions.silent is true (or when neither forceNewSession nor createIfNone is set), or add an explicit opt-out flag for env-token auth.

		const envResult = await this.tryInitializeFromEnvironmentToken(authProviderId);
		if (envResult) {
			return envResult;
		}

src/github/credentials.ts:171

• Env-token initialization bypasses the scopes/requireScopes logic used for upgrading sessions (e.g. getHubEnsureAdditionalScopes() calls initialize(..., SCOPES_WITH_ADDITIONAL, true)). With the current early-return, the code will report success without ensuring/recording the requested scopes, which can cause repeated upgrade attempts or later authorization failures. Consider plumbing scopes/requireScopes into tryInitializeFromEnvironmentToken and either (a) validate the token has the needed scopes or (b) explicitly set the store’s effective scopes to the requested set when env auth is used.

		const envResult = await this.tryInitializeFromEnvironmentToken(authProviderId);
		if (envResult) {
			return envResult;
		}